1. The Field of the Invention
The present invention relates to managing cached content. More specifically, the present invention relates to registering for and receiving database table change notifications that can be used to invalidate cache entries.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another to form both wired and wireless computer networks over which the computer systems can communicate electronically to share data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, electronic conferencing, web browsing) include electronic communication with one or more other computer systems via wired and/or wireless computer networks.
In particular, the World Wide Web (“WWW”) has become an important mechanism for exchanging information. Generally, content on the WWW is accessed in a client/server model. A “Web browser” at a client computer system sends a request to access content that is maintained by a “Web Server” at a server computer system. When appropriate, the Web server subsequently provides the requested content to the Web browser.
One way of making content available to Web browsers is for a Web developer to create a static Web page that includes a number of hard-coded computer-readable instructions, such as, for example, in HyperText Markup Language (“HTML”). The static Web page is then stored in a location (e.g., at the server computer system, in a network connectable database, etc.) that is accessible to the Web server. In response to a request from the Web browser, the Web server can transfer the static Web page to the Web browser (e.g., as a result of user input causing the Web browser to access a Uniform Resource Locator (“URL”) that corresponds to the static Web page). Upon reception of the static Web page, the Web browser can present the content of the static Web page (e.g., text, graphics, etc.) at the client computer system.
To conserve network resources, the Web browser may also cache a copy of the static Web page at the client computer system (e.g., in system memory or at a mass storage device). When the static Web page is subsequently requested, the Web browser attempts to locate the static Web page from cache before initiating a new network request to the Web server. If the static Web page is located in cache, the Web browser retrieves the cached static Web page instead of initiating a network request. Since locally stored data can be accessed more efficiently, caching static Web pages at the client computer system reduces the latency associated with presenting the content of the static Web page.
Frequently requested static Web pages can also be cached at a server computer system (commonly referred to as output caching) to reduce latency. For example, a frequently requested static Web page can be cached in system memory at the server computer system so the static Web page does not have to be retrieved from a mass storage device each time the static Web page is requested. Because of their static nature, static Web pages can be cached (at a client or server computer system) for long periods of time, potentially indefinitely.
However, the use of static Web pages essentially prevents real-time or custom data from being presented by a Web browser. Often, it is desirable to present dynamic data (e.g., daily sales figures, current stock prices, etc.) at a Web browser. Accordingly, mechanisms for including dynamic data in dynamic Web pages that are to be presented at a Web browser have been developed. One mechanism for including dynamic data in dynamic Web pages is the use of modular pieces of computer-executable instructions (commonly referred to as “scripts”).
Scripts can be developed using scripting languages, such as, for example, JavaScript and VBScript, and embedded along with HTML and Extensible Markup language (“XML”) instructions in a page file (e.g., an Active Server Pages (“ASP”) file). When a request for a dynamic Web page is received, the server computer system redirects the request to a processing module (e.g., an ASP module) that processes a corresponding page file. The processing module executes any scripts included in the page file, and generates appropriate HTML instructions to return in response to the request. Scripts can include computer-executable instructions for accessing data from dynamic locations, such as, for example, from a database that maintains current sales figures or stock quotes. Since scripts are executed essentially at the time a request is received, scripts can be utilized to generate dynamic Web pages that include real-time data.
Similar to static Web pages, a dynamic Web page can be cached to provide more efficient access to the dynamic Web page. However, dynamic content (e.g., a price quote) included in a dynamic Web page is typically valid for a limited time (e.g., until values at the location where the dynamic content was retrieved change). Often, dynamic content (e.g., a stock quote) will be valid for a very short period time, for example, only a few seconds. When the value of dynamic content changes, cached dynamic content can become invalid. For example, when a stock price changes from $20.00 to $21.00, a cached value of $20.00 is not valid (or even correct). When invalid dynamic content remains in cache, there is some potential for a Web server to provide incorrect dynamic content to a Web browser. For example, when an invalid stock price remains in cache, a Web server might retrieve the invalid stock price from cache instead of re-executing a script to retrieve an updated stock price from a database. Accordingly, cache management mechanisms that attempt to insure the validity of cached dynamic content have been developed.
Some cache management mechanisms automatically remove dynamic content from cache at specified time intervals, such as, for example, every ten minutes. However, if a dynamic content value changes between specified time intervals there still exists a potential for an invalid dynamic content value to remain in cache. For example, if a specified time interval is five minutes and a dynamic content value is updated one minute after it is cached, the dynamic content value is invalidated but will remain cached at least for four minutes. During those four minutes, the Web serer may incorrectly retrieve the cached dynamic content value instead of running a script to retrieve the updated dynamic content value.
Further, removing content at specified time intervals may cause a value that is still valid to be removed from cache. For example, if a specified time interval is ten minutes and a dynamic content value remains valid ten minutes after it was cached, the dynamic content value is still removed from cache. Thus, the potential for more efficiently retrieving the dynamic content value in response to a subsequent request is prevented.
Other cache management mechanisms monitor files (e.g., XML files) stored at server computer system and invalidate cached dynamic content values from a monitored file when the monitored file changes. Yet other cache management mechanisms monitor cache entries and invalidate one cache entry when another cache entry is invalidated. Accordingly, some cache management mechanisms cause the validity of cache entries to be dependent on time, a corresponding file, or another corresponding cache entry.
However, existing cache management mechanisms (including those that use time, file, and cache dependencies) are not well suited for invalidating cached dynamic content values retrieved from locations that are external to the server computer system. For example, a Web browser may request a Web page that is to include dynamic content values from a number of different tables in a database. Accordingly, a page file with appropriate scripts can be processed at the server computer system to retrieve the dynamic content values and generate appropriate HTML instructions.
However, retrieving data from a database consumes both network and database resources. If calculations are to be performed on retrieved data, additional server computer system resources are also consumed. Further, it may be that a server computer system simultaneously queries a database for a number of different portions of dynamic content that will be included in different Web pages. It may also be that a number of server computer systems each access dynamic content from the same database.
Thus, a single database may simultaneously provide dynamic content to a number of server computer systems, where each server computer system simultaneously queries the database for different portions of dynamic content. As a result, the single database becomes a resource that is shared among the number of server computer systems and thus potentially limits scalability. That is, the addition of more server computer systems will not necessarily increase performance, since each server computer system is limited at least by the time needed for content to be retrieved from the single database. Further, when content is pre-maturely removed from cache (e.g., at a specified interval) a server computer system may be required to re-query the database, even if the dynamic content in the cache is still valid. In a multi-server environment, pre-mature removal of cached content can place an unnecessary burden on the resources of a shared database, thereby also, and possibly significantly, limiting scalability. Accordingly, what would be advantageous are mechanisms for configuring cache entries to be dependent on and invalidating cache entries based on changes in database tables.